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A. | PROJECT OBJECTIVE _ 


The objective of the SAFE Project is to assist in the 
analytical process by providing to the analyst advanced 
data processing techniques for manipulation and analysis of 
raw intelligence and to aid in the production of finished 
intelligence. Provisions must be made for the use of 
computerized analytical techniques as they are developed 
to augment the intellectual process. 


This set of capabilities will be made available in the 
form of a computer/terminal network providing immediate auto- 
matic alerting and distribution of incoming raw intelligence 
based on information content, generalized search and retrieval 
of data bases for items of interest, building of personal and 
organizational files, routing of intelligence, distribution of 
repository material, and composition/editing of finished 
intelligence. 


The following pages outline the management savanen 4 to 
carrying out this objective. 
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oe MANAGEMENT APPROACH 


. “The “SAFE a eee will be carried ‘out. as an Agency 

-- in-house project. The system will be defined, designed, 

~. developed, and brought to operation under the management of © 
the SAFE Project Management Organization (PMO), using a mini- 
mum. number of Agency staff positions supplemented by con- 
tractor personnel. While some predefined tasks may be 

* contracted with industry when such action will further a 

jf successful, implementation, the SAFE management concept does 
|} not envision the selection of a: prime contractor with total 
responsibility for developing the system. It is planned, 
rather, that major elements of the system will be purchased 
and that these elements will be integrated in house, again 
using contractors as required. 


; The customer for SAFE will be the Central Reference Service 

(CRS) acting for the DDI and DDS&T production offices. The 
Systems Analysis Staff within CRS (SAS/CRS) will be responsible 
for interfacing with users for definition of the system's 
functional characteristics and performance criteria. 


The project will be carried out through five distinct 
phases, defined as follows for planning purposes: 


I. Definition of Requirements: SAS will be 
responsible for writing the functional requirements 
of the system which will be reviewed by the SAFE 
(PMO) and, through a process of continuing feedback 
and coordinating meetings, the two organizations will 
arrive at a mutual understanding of the requirements 

and the implementation ramifications of these 
eae SF ai requirements; changes in the basic requirements _ 
: will be reviewed by the user representatives 
-as these ramifications suggest they must. The 
final output will be a Requirements Document which 
-will. be approved by SAS, SAFE PMO, and the Joint 
Steering Committee made up of the ‘Director and Deputy 
; Director of Joint Computer Support (OJCS), and the 
ee ~~ Director and Deputy Director of CRS. This Require- 
Peas -- -ments Document will be the basis for an industry 
briefing to solicit ideas in key problem areas 
and foe system design, cae 
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~ TI. System Design and Analysis: The SAFE. 

“PMO will develop a systems architecture capable of © |... 

“meeting these requirements. The results of this ac- ~ 
- tivity will be an External Reference Specification 
“.-CERS) outlining the external characteristics of the_ 
system. This specification will require the approval 
of SAS, SAFE PMO, and the Joint Steering Committee. 
‘This systems architecture will be the basis for an 
industry briefing to be made prior to the issuance 
of requests for proposals (RFP's) for major elements 
“of the system in order to solicit ideas and approaches 
“to refine the RFP's. The logistics and communications 
requirements will be specified during this phase. =. 
Additionally, the coordination and responsibilities of © 
the SAFE project and the Office of Communications 
Cable Dissemination System (CDS) and the CRS Automatic 
Storage and Retrieval (ADSTAR) projects will be 
stabilized during this phase. These projects are 
directly related to the SAFE system functions and, 
therefore, the coordination and compatibility of 
these projects are extremely important. ; 


III. System Development, Acquisition and Test: 
This phase Will involve the acquisition of hardware 
and development of software. Software packages may 
include those defined for outside procurement as well 
as the in-house development of those additional ele- 
ments necessary to produce the final system. The 
system will be documented by an Internal Reference 
Specification (IRS) which requires SAFE PMO approval 
only. Test activity will be a continuation of the 
Test and Quality Assurance (T&QA) functions initiated 
at the beginning of the design cycle to ensure that a 
consistent and structured test program is in place to 
meet the reliability requirements. The results of 
‘this activity will be an initial system in place, ready 
for acceptance testing by CRS. a 


IV. -Phasing Into Service: During this phase, CRS 
will run acceptance tests on the system. The system 
will be phased into service cither by function or by 
organization over a period of ‘time such that all avail- 
able functions become operational. It is anticipated 
that some functions of the system may be deferred and 
brought into operation later than others, hence the 
phasing into service may take place in a number of steps. 
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eae te aN a erations ond Seon venance= - During this” ~ 
ee the system will be operated as a special single- 
“purpose data processing center by OJCS, “and those 
- functions which have been deferred or seeined as 
. additions during the development will be developed and 
brought on-line as system enhancements. This will be 
.- the on-going phase of the SAFE Project, which includes 
_-- tHe maintenance of the operating environment and 
“applications software. The organizational responsibilities 
for* application software maintenance, exploration of 
system enhancements, and database management have not 
been defined in detail at this time. 
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C. 


The SAFE Project Sisanapavion is. shown in Figuré 


- ORGANIZATION | 


Petite mare 


“The in-house organization will consist of managers, technical 

and support personnel required to define and manage the over- 

all effort. Contractors will be used primarily as consultants 
--and implementers. As noted before, it is not’ planned that the 
“total. system will be contracted for. independent development, 


oa although some elements may be so contracted. 


The one cicnal responsibilities of the sredhinarioaal 


components are as follows: 


SYSTEMS DEVELOPMENT: 


Responsible for 


System Design 

Coordination with SAS on functional 
and processing requirements. 

Software: specifications and 
implementation 

Acquisition of software "packages" 

Methodology of implementation 

Software/System documentation 

System Integration 


OPERATIONS DEVELOPMENT: 


Responsible for - 


Participant in system design 

Physical installation plans and - 
execution 

User interface characteristics 

System Operation plans and 
training 

Systems Operation - including 
staffing oo: 02 

Recommendations to PD/SAFE on 
hardware selection — 

Coordination with SAS ‘on terminal 

specifications and selection 

Specification of communications 
and logistics. requirements. 
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QUALITY ASSURANCE AND TEST: | 
oo. ss" Responsible for..-. Setting quantitative reliability _ 
HES ast ors ; objectives that concur with ‘the de 
functional and processing requirements. 
- Test plan and execution to ensure 
. ‘meeting objectives - 2 - 
' - Coordination of test program with 
i system design and development 
- . Functional test program for system 
- Go no-go recommendation to PD/ 
7 SAFE at.each phase 
- Interim SAFE support 


PROJECT CONTROL: 


Responsible for - Developing project schedule 

and monitoring progress 

- - Financial management 

- Control of all documentation 

-~- Primary OL interface for pro- 
curement 

~ Monitor of all contracts 

- Briefing aids 


The Collateral Support Committee will be made up of senior 
representatives of OL, OC, OS and any other organizations found to 
have responsibility for activities upon which SAFE depends but 
not having direct Project responsibility. This group will be 
convened periodically by PD/SAFE to ensure that these support 
activities are planned in concert with SAFE plans, and that they 
are occurring as planned and will not impede SAFE progress. 


Outside Consultants, as noted in the organizational chart, 
will be used to critique the key system characteristics as re- 
flected by the Requirements Document and system specifications. 
They willbe called upon initially to critique the Requirements 
Document after an initial review by the SAFE Project and SAS in. 
order to.ensure that the requirements can be met, and that the 
‘requirements reflect the current state-of-the art for on-line 
data systems. They will be called in to review the initial 

system definition work and the final systems specifications in 
order to ensure that the system as outlined meets the require- 
ments, takes maximum advantage of current and immediate future 
technology and is achievable. | ee 
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STAFFING ee ee me ae 

The staffing for the SAFE Project will be: made aa : 
taff slots in FY-76 with an additional danne STATINT 

FY-77. The remainder of the team will consist of contract 

personnel, either contracted individually or as teams. The L 

initial plans for in-house staffing are shown in Figure la. a 

The exact contractor staffing will be discussed as a function. 

of the work phasing rather than by fiscal years, and will be in 

final form only after the first analysis of the Requirements 


Document. (An initial estimate of Agency start through 1980 
is shown in Figure 1b.) ; 


STATINTL . 


INTERIM SAFE SUPPORT 


As shown in Figure 2, there are currently two organizations 
within CRS involved in the support of Interim SAFE. These are 
SAS and Support Services Division (SSD). The OJCS SAFE PMO will 
assume responsibility for the maintenance of application pack- 
ages which are unique to SAFE. These packages are as follows: 
COLTS, OLTA, and, LITTLE SQUIRL. Since personnel previously 
involved in the maintenance of these packages have been trans- 
ferred to the SAFE Testing § Quality Assurance organization, and 
since it is not a full-time activity to support these packages, 
responsibility for Interim SAFE will be carried out by the Test- 
ing § Quality Assurance Branch. 


SAS in CRS will have responsibility for user interface and 
any new user support requirements. be 


SAFE STEERING COMMITTEE 


The SAFE Steering Committee, as shown in Figure 2, will be 
made up of the D/CRS and D/OJCS, their Deputies, and such other 
people as they may select. The Committee will be chaired by the 
D/CRS, : 


The flow of requirements, specifications and day-to-day 
work activity coordination will be between the PD/SAFE and 
C/SAS. Status and work direction will be reviewed periodi- 
cally by the SAFE Steering Committee, and all final requirements 
and external specification at the system level will be approved 
by the D/CRS and D/OJCS as the Steering Committee. These re- 
quirements and specifications will then constitute the mutual 
agreement on the system to be developed. 
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Dd, FINANCIAL MANAGEMENT PLAN 


. The major financial resources for SAFE will be included ~~ 
in the DDI Management Staff budget. CRS will be responsible. Ce 
for preparing budgetary justifications for SAFE “in ‘coordination °°” 
with OJCS; the major financial resources for SAFE will be ack aa 
included in the DDI Management Staff budget. After appropriate — 
approval, funds will be transferred to OJCS for contractual 
services, equipment, and facility procurements and other 
services. OJCS will budget for its staff personnel assigned 

to the SAFE Project. The APD/SAFE, Project Control will 
establish controls for each task and for overall project costs. 


The budget will be allocated against tasks such that 
progress and accrued cost can be related. Each manager will 
be responsible for managing and reporting the cost and progress 
of his tasks and for providing CRS with whatever data is needed 
for Project SAFE budgetary justifications. 


Cost-to-date and cost for current period will be reported 
monthly to the D/OJCS with variances of more than five percent 
explained. 


The Project Control Staff will recommend the allocation of 
funds after receipt of an approved task plan. The monthly proj- 
ect cost summary will report total budget, actual versus planned 
cost-to-date, allocated versus total budget, and projected cost 
at fiscal year end. The total project cost projection will be 
reported semi-annually to the SAFE Steering Committee. 


Contracts will be let as CPF, time-and-material or prefer- 
ably, fixed-price. They will be predictable and measureable 
and will be reported both as elements of task cost and 
as individual line items. 


The total funds programmed for SAFE to date are as follows: 


FY 1976 FY 1977 
h DDI $3,000,000 $10,000,000 
OJCS + ie TS O00 ___ 575,000 


TOTALS $3,273,000 $10,575,000 
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planning and coordination with other organizations in 
“progress at the date of this document. 


E. MILESTONES 


er ww en S ; 
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Dates beyond 1 January 1976 are subject to detailed 


There may therefore 


be changes as dictated by outside constraints or planning | 


dependencies not yet defined, 


minor. ) 
Es Establish support plan for Interim Safe. 
23 Confirm and refine plan for supporting and 
processing Interim SAFE during crisis. 
Sa Obtain one complete set of first-round func- 
tional Requirements Documents. 
4, Conduct formal review of functional require- 
ments with Technical Review Panel. 
Do. Complete.review and generate final Require- 
“nents Document, mee aps 
6. Identify and confirm systems security require- 
ments. 
7s Confirm SAFE/CDS system integration and/or 
interfaces. 
8. Present initial industry briefing on Require- 
ments. 
9, Identify systems communications requirements. 
10. Define system architecture, 
11. Define site requirements - Rough Order of 
Magnitude. 
dees Present second industry briefing (on archi- 


tecture). 


They are expected to be 


09/15/75 
09/15/75 


09/30/75 
12/19/75 
12/31/75 
01/15/76 
01/15/76 


02/01/76 


04/15/76 


‘10/01/76 


11/01/76 


11/15/76 
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Fl, CONTRACT EFFORT 


The actual contract effort can not be: defined at this 


-time but will be specified as the requirements and. ‘architecture | 
are solidified. For management planning of contract defingtton < * 


the development effort may be defined as BOT EQNS oo 
1. Systems Design and Analysis 
2. Terminal and Communication Sub-system 
3. System Software Development, 
a. Data Management System Development 
b... Back-up Mode and Communication Mode 
c. Operating System 
4. Equipment Procurement, Installation and Support 
a. Mainframes (mini and full size) with Basic 
Support Configuration 
b. Data Storage 
c. Terminals 
d. Supplies 
5. Operations 
6. Facility Preparation 
7. Applications Software Development 
8. Potential Special Development 
a. Hardware Text Search 
b. Microfilm Retrieval 


c. Communications Facility 
d. Remote Document Viewing 


It is planned that contract effort in these areas will be 
under close control by the project management to ensure proper 
integration of the final result. 
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_F2. FACTORS IN DETERMINING IN-HOUSE VERSUS OUTSIDE EFFORT 


It is noted in the organizational discussion that work 
done in-house will be done primarily by staff and contract 
personnel under the direction of Agency management. There °° = 
will be functions, however, which may be amenable to outside ~~ 
development, and the following will be some of the factors 
considered in determining which course to take on these ~ 
activities. gO eas a 


1. Security: Workload for outside contracting 
must be defined to eliminate security constraints, or 
must be let to an organization having facilities and 
personnel cleared to the necessary level. 


2. Stability of Requirements: If the require- 
ments are not precisely defined or are questionable, 
then it is far more difficult to contract this effort 
than to control it in-house. Poorly defined or change- 
able requirements result in changing technical direc-, 
tion; this leads to contractual negotations on change- 
of-scope with lost time and pyramiding costs. 


3. Conciseness of Task Definition: Tasks to be 
contracted must be precisely defined, particularly if 
bid on a fixed price basis. While lack of conciseness 
on in-house work may result in wasted motion and cost 
and some redirection during the program, on a contract 
effort it will likely result in the delivery of an un- 
satisfactory product. 


4. Required Flexibility: Many of the functions 


of the initial implementation will change to a degree 
during the definition as they are exposed to the ulti- 
mate users. This will be a problem to control, regard- 
less of how the effort is undertaken. In particular, 
it will be difficult to control under fixed cost con- 
straints, although it would be amenable to CPFE manage- 
ment or in-house effort. 


5. Control: It is difficult to control technical 
effort in a new application. In the event of problems, 
there is more immediate feedback if the effort is closer 
to the Project Management team or in-house. As the ef- 
fort gets further away, there are more people and time 
involved in trying to take corrective action before the 
out-of-control condition comes to light. This would 
indicate that the effort, which may be farmed out, should 
be that which has least impact on other elements of this 
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6. Cost: Cost is probably minimum of a well- 
defined package put out for competitive bids by com- 
petent outside organizations. It is least controllable 
under cost-plus contracts or under in-house efforts. 
(The only way to control cost on labor-intensive ac- 
tivities is to control the technical schedule. )} 


7. Available Talent: The primary limiting 
factor for in-house effort is availability of suffi- 
cient numbers of the proper talent levels. It is par- 
ticularly costly, in terms of schedule and dollars, to 
undertake effort for which the technical resources are. 
not available. . 


8. Scope of Effort to be Integrated: A limit- 
ing factor on the practicality of outside development 


is the number and complexity of sub-systems with which 
that effort must interface. Where sub-systems of any 
complexity must interface with one another, this effort 
must be done by the organization having final system 
responsibility. 


9. The Market Place: When systems and software 
houses are fully Toaded, their inclination is to take 
only tasks which encompass a significant amount of 
responsibility and provide an opportunity for very sub- 
stantial profits and/or residual products. When the 
market becomes tight, these houses become more amenable 
to time-and-material contracts, either on individuals 
or groups of people. 


10, Need for Support after Installation: In-house . 
competence is needed for post-installation support. This 
competence must be acquired in-house during development. 
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BS. MANAGEMENT OF SAFE PROCUREMENTS 


The outline. below shows. the management structure, respon- 2: 


sibilities, and possible Agency component representation: that. ote 


will oversee: 


The writing of RFP's’ © . Gf See eee 
- Evaluation of the proposals | q 
- Awarding of contracts. 


It is anticipated that system components will be acquired 
from several vendors and in varying volumes rather than in one 
overall procurement. Like elements will be consolidated for 
contract purposes to provide maximum price leverage in negotia- 
tions, i.es, all central processors or all memories. On the 
other hand, sub-systems such as terminals, communications, mini 
or special computers, etc., will be procured separately to per- 
mit competitive bidding by a wider range of vendors, to take 
advantage of special expertise available in industry, and avoid 
over-dependence on and vulnerability to one vendor. 


Therefore, a number of RFP's will be generated, and a num- 
ber of contracts will be let to make up the total system. The 
range of contracts may be from one-hundred thousand to several 
million dollars. 


The following outlines the transitory organizations involved 
in the procurement process and their responsibilities. The ob- 
jective is to ensure proper participation by concerned organiza- 
tions, fair procurement practices, and maximum value to the 
government for the expenditure involved. 


IT. SOURCE SELECTION AUTHORITY: 

D/OJCS - Responsible for: 
Final Agency selection of the winning 
bidder based on technical assessment, 
price, and other factors. 

D/OL - Responsible for: 

1) Final Agency contract negotiation upon 

receipt of obligation of funds authori- 


zation. 


2) Contract award to the successful bidder. 
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II. SOURCE SELECTION BOARD | 


1) Responsible for: 


Recommending a winning bidder to the: °"*” 
Source Selection Authority. The recom- 
mendation is based, in part, on a review. 
of the proposal evaluation performed by 

the Source Evaluation Board. 


2) ‘Composition: 


PD/SAFE (Chairman) 

CRS/SAS 

OL/PD/ADP&ES 

APD/SAFE/SYSTEM DEVELOPMENT* 
APD/SAFE/OPERATIONAL DEVELOPMENT* 
APD/SAFE/PROJECT CONTROL* 
APD/SAFE/TESTING & QUALITY ASSURANCE* 


III. SOURCE EVALUATION BOARD 


1) Responsible for: 


Reviewing RFP's, establishing evaluation 
criteria, evaluating proposals, and rank- 
ing bidders based on technical and cost 
consideration, 


Establishing bidders' list and its subse- 
quent submission for review to the RFP 
Review Panel (below). 


Presenting recommendations and rationales 
to the Source Selection Board, 


z). Composition: 


*when appropriate 


APD/SAFE/OPERATIONAL DEVELOPMENT (Chairman) 
APD/SAFE/PROJECT CONTROL 
APD/SAFE/SYSTEM. DEVELOPMENT 


APD/SAFE/TESTING §& QUALITY ASSURANCE 
CRS/SAS - 
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IV. REP REVIEW PANEL 
1) Responsible for: 
Reviewing the bidders" list - 


Predistribution review of the RPF to 
assure its technical, administrative, 
and legal soundness and clarity 


Recommending changes in the bidders' 
list and RFP to the Source Evaluation 
Board. 


2) Composition: ie 


APD/S/PC (Chairman) 

CRS/SAS- 

ORD/Data Processing Research Division* 

OL/Real Estate § Construction Division/ 
Headquarters Engineering Branch* 

OS/Information Systems Security Group 

OC/Engineering/Engineering Support Division* 

APD/S/OD 

APD/S/SD 

APD/S/T&QA 


V. SAFE PROJECT 

Responsible for writing RFP's. Hardware RFP's 
will be written by Operations Development. Software 
and Systems Integration RFP's will be written by 
Systems Development. Project Control will be respon- 


sible for processing all RFP's through the PuOchnement 
groups outlined above. 


* when appropriate 
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G. STUDY METHODOLOGY 


as the specifications are further refined. A problem log will 
be established in which each problem will be defined as it is 
identified and potential approaches will be listed... These state- 


- An example of these problems would be ‘the remote viewing 
of centrally filed hardcopy documents. 


Problem Statement: There is a need to view re- 
pository documents at the analysis site, to page back 
and forth through these documents, and to produce 
local hard copy upon command, Documents will normally 
be on microfilm, . 


Potential Approaches: 


Regional Microfilm Storage/Viewing Stations 
Central Video file with TV transmission to 
the viewing site . 

3. Automatic picking of microfilm with video 
scan (TV) distribution or high-speed, 
scan-facsimile transmission 

4. If time requirements are not critical, use 
fast-copy service and either manual or 
pneumatic tube distribution 

5. Compute Input Microfilm (CIM) 


Ne 


NOTE: Cost will be one of the critical factors in 
final determination of competing architectures. 


Such problem statements will provide the basis for group 
problem-solving sessions where technical personnel outside the 
Project, as well as Project personnel, can participate in out- 
lining various problem Solutions. The problem log will be uséd 
only for major technical problems rather than normal develop- 
mental difficulties, 
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H. PROJECT REVIEWS AND REPORTS © !"r i022. 
In addition to the weekly abbreviated reports and the 
Monday CRS-OJCS Interface Meetings and the bi-monthly MBO re- 
ports, a formal review will be held monthly with the Joint © 
Steering Committee. This review will cover progress against - 
plan, financial commitment to date, status of key problem 
areas, and plans for the following month. | ; 


External Reference Specifications will be reviewed with 
the Joint Steering Committee and with the using analyst popula- 
tion as they are completed. These reviews will provide feedback 
to the Project within a time frame when action can still be taken 
to correct deficiencies noted. 


Additionally, PD/SAFE will establish a system of design re- 
views for each element of the system to ensure overall architec- 
tural integrity, to critique the design, and to apply proper 
management judgment to design decisions. The review panels will 
be selected as appropriate to the subject matter. 
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I. INDUSTRY RELATIONSHIPS 


It is the intent of the Project to gain the maximum pos- 
sible advantage to the Agency from the meaningful participation 
- of the industrial community in Project SAFE. Procurements will 
-be open.and competitive and the specialized knowledge of various 
segments of the industry will be brought to bear on the develop- 
ment of the system and preparation of SAFE specifications. To 
this end, two industry briefings are currently planned as follows: 


Within two months of the completion of the Re- 
quirements Document, industry will be invited to a 
briefing on the summary of the requirements defined 
to give them a picture of the overall SAFE environ- 
ment and requirements, and to solicit voluntary feed- 
back on possible approaches to meet some of these 
requirements, and on the realizability of the require- 
ments in general. This should also help many com- 
panies to determine whether they wish to participate 
further in the later phase of SAFE development. 


After a systems architecture is defined which 
appears to meet the SAFE requirements, another brief- 
ing will be held to outline the proposed architecture, 
with the objectives of soliciting industry reaction 
concerning the approach taken, and to elicit novel 
approaches which perhaps have not been incorporated. 
We would anticipate that after this briefing, there 
would be meaningful responses from the major hardware 
and. software companies reflecting their best efforts 
to solve the problems or to influence the solution 
which will be embodied in the request for proposals 
for major elements of the system. 


The Office of Logistics will be involved in the preparation 
of these briefings in order to avoid creating an unrealistic set 
of expectations within the community. Their advice will also be 
sought prior to this time to avoid establishing conflict of 
interest situations which might preclude some companies from 
bidding in later phases of the Project. 
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J. SYSTEM DOCUMENTS HANDLING 


The SAFE Requirements Document will. be generated by CRS/ 
SAS with such assistance as may be requested from the SAFE 
Project. It will be transmitted to the PD/SAFE for review and 
will be considered final when signed jointly by PD/SAFE, C/SAS 
and the SAFE Steering Committee. This will require review of 
interim specifications and collaboration on a continuing basis. 


This "System Requirements Document'' will become the system. 
functional objective for SAFE development. A change to this 
document, once approved, will require approval as noted in the 
Configuration Control section of this plan. 


The system design will be defined in an "External Reference 
Specification" (ERS), which reflects system function and behavior 
as seen from an external point, and by an "Internal Reference 
Specification" (IRS), which documents the internal design (which 
a user might never perceive). The ERS must embody the perform- 
ance documented in the Systems Requirements Document and hence 
requires concurrence by C/SAS and PD/SAFE as well as the SAFE 
Steering Committee. The IRS requires SAFE/PMO approval only. 


A "System Reference Manual" will be written from the final 
ERS and will constitute the complete documentation required to 
use the system in any application. 


An "Operational Procedures Manual" will be written for 
operators. (Users will, however, employ tutorial aids and 
Simple instruction rather than manuals.) The user tutorial 
aids will be written by SAS. 
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K. SDE Bees CONTROL 


Lae In godess to ensure development of -an Spetational system, 
the specification, design, configuration, and intermediate 


-o. products must be brought under management control. This will > 
be done by designating "Control Documents" and specifying pro-. 


eure for approval of and changes to these documents. 
The Control Documents are: 


ae Systems Requirements Documents 


a External Reference Specification 
ae Internal Reference Specification 


The levels of approval required for each document are as 
follows: 


Requirements ERS IRS 
Initial PD/SAFE, C/SAS, PD/SAFE, PD/SAFE 
Approval Steering Committee C/SAS, 


Steering Com. 


Class I Same Same Same 
Changes 

Class II -- PD/SAFE PD/SAFE PD/SAFE 
Changes =) 


Class I changes are those which substantially alter the 
functional characteristics of the system ina mete eee way 
as seen by the user. 


Class II changes are those which cians or correct a docu- 
ment without substantially altering the functional characteristics. 
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Once approved, these documents will be under the control 
of APD/Project Control who will pre-screen all change requests. 
These requests will be reviewed at the appropriate level, and 
recommendations made to the PD/SAFE who will approve or reject 
them, or refer them to the Steering Committee as appropriate. 


As the system is further defined, the Control Documents 
may be further broken down for ease of management, and at that 
time specific controls will be specified for each new element. 
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